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REMARKS 

The Final Office Action mailed June 1, 2009 has been carefully considered. 
Reconsideration and allowance of the subject application, in light of the following remarks, are 
respectfully requested. 

Claims 1-21 are currently pending, claims 22-24 having been previously cancelled. No 
claims have been added or cancelled by this Response. No claims have been amended by this 
Response. 

In view of the fact that no changes have been made to the claims by this Response, it is 
respectfully submitted that this Response is entitled to consideration and entry as a matter of 
right. 

In the Final Office Action, the Examiner has rejected claims 1, 4-5, 7-8, 11-12 and 19-21 
under 35 U.S.C. § 103(a) as being unpatentable over Lakkakorpi (U.S. Patent No. 7.489.632 ) in 
view of Daoudetal. (U.S. Publication No. 2002/0087694 )/ Eizak (U.S. Publication No. 
2003/0027595 ). The Examiner has also rejected claims 6 and 9-10 were rejected under 35 
U.S.C. § 103(a) as being unpatentable over Lakkakorpi (U.S. Patent No. 7.489.632 )/ Daoud et al . 
(U.S. Publication No. 2002/0087694)/Eizak (U.S. Publication No. 2003/0027595) . further in 
view of Rundu (U.S. Publication No. 2004/0117794 ). Additionally, claims 2-3 and 13 have been 
rejected under 35 U.S.C. § 103(a) as being unpatentable over Lakkakorpi (U.S. Patent No. 
7.489.632 ) /Daoud et al . (U.S. Publication No. 2002/0087694 ) /Eizak (U.S. Publication No. 
2003/0027595 ). further in view of Swildens et al . (U.S. Patent No. 7.346.676 ). Furthermore, the 
Examiner has rejected claims 14-18 under 35 U.S.C. § 103(a) as being unpatentable over 
Lakkakorpi (U.S. Patent No. 7.489.632 ) in view of Daoudetal. (U.S. Publication No. 
2002/0087694). Applicants respectfully submit that these rejections of the claims cannot be 
maintained, and should be withdrawn. 

At page 3 of the Final Office Action, the Examiner acknowledges: 2 



At pages 2-3 of the Final Office Action, the Examiner argues that Lakkakorpi discloses using a "Q-value." 
However, as is well known to those of ordinary skill in the art, a "SIP Q-value" (see claim 1) is a specific Session 
Initiation Protocol (SIP) parameter that has specific pro pcrltcs uses according to SIP . See, e.g., pages 35 and 46 
(§§8.1.3 and 10.2.1, respectively) of RFC 3261. Nothing in any of the documents relied upon by the Examiner 
(including Lakkakorpi) discloses use of such SIP Q-value in any fashion, much less, in the manner argued by the 
Examiner at pages 2-3 of the Final Office Action or in the claims. Indeed, the term "Q-value" is nowhere found 
anywhere in Lakkakorpi, at all! Furthermore, no combination of the documents relied upon by the Examiner with 
RFC 3261 would disclose or suggest specific features of the claims. 
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Lakkakorpi fai t lssdos« tor its >n < > t < «J a p lira ? f SEF 
entities, where the G-vaJue is an integer value based on both (1) a contact 
priority and (2) a number of cells or an amount of information being processed 
for a call; and where each toad broker is a beck-to-back user aserrt- 
(Final Office Action, page 3). 

However, the Examiner argues that Daoud and Ejzak disclose these features that the 
Examiner acknowledges to be missing from Lakkakorpi. More specifically, the Examiner 
argues: 

Daoud discloses where the Q-va?ue is an integer value (Figure 4: tern 
420} based on both {1) a contact priority and ([0043]. [0047]- Figure fi: item 620) 

(2) a number of calls or an amount of information being processed for a 
cait. (10034]; current toad) 

Ejaak discloses a session initiation protocol and a plurality of SIP entiSes 
([0030]) and a back-to-back user agent. {[0116]} 

(Final Office Action, page 3). 

For the convenience of the Examiner, Daoud's Figure 4 is reproduced below: 
FIG. 4 
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(Daoud Figure 4). 
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Daoud describes "Service Level 420" in Figure 4 illustrated above as: 
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[0039] The service level 420 can be any suitable indicator, 
such as but not limited to a number on a scale of one to ten, 
a category of service, the time (e.g., weekday or weekend), 
a user identification (e.g., userl, user2, administrator), a 
transaction type (e.g., email, video), a combination thereof, 
etc. Furthermore, the service level can be based on infor- 
mation about the monitored servers obtained by polling the 
servers, predefined service specifications, etc. Likewise, the 
servers can be ranked relative to one another, relative to the 
types of transactions processed, etc. 

(Daoud, paragraph 39). 



In paragraph 34 of Daoud, specifically relied upon by the Examiner, Daoud discloses: 

[0034] In another embodiment, the requested level of 
service may be automatically assigned to a transaction 200. 
That is, the requested level of service may be assigned by a 
network device (e.g., a workstation, router, etc.) or an 
application (e.g., an operating system, the originating appli- 
cation, an applet, etc.). Suitable program code can be 
included at the network device and/or the application to 
assign the requested level of service based on a fixed 
parameter(e.g., a user ID, application ID, passcode, etc.), a 
dynamic parameter (e.g., the time of day, current load, etc.) 
or a combination thereof. 
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(Daoud, paragraph 34). 
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Daoud's paragraph 43, also specifically relied upon by the Examiner, discloses: 

[0043] In FIG. 5, the server pool 500 includes a premium 
group 510, a standard group 520, and a low priority group 
530. The servers 511, 512, and 513 (A, B, and C, respec- 
tively) are part of the "premium" group 510. For example, 
the premium group 510 can include high-speed, high-capac- 
ity servers. In addition, the premium group 510 can include 
additional servers and backup servers so that there is always 
an available server in this group. Access to these servers can 
be reserved for a department with high demand requirements 
(e.g., the CAD department), for high priority transactions, 
for customers paying a fee to access these servers, etc. The 
standard group 520 can include average-speed, average 
capacity servers. Access to these servers 521, 522 (JD and E) 
can be designated for a sales/marketing department that 
requires only average processing capacity, or can also be 
available on a fee-basis. The "low priority" group 530 can 
include older and/or less expensive servers 531 that do not 
perform at the predetermined standards of the standard 
group 520 or the premium group 510. These servers 531 can 
be used for low-priority email, backup jobs, transactions 
requested during off-peak hours when timeliness is not as 
important, etc. These servers can be designated as a group 
530, or simply be unclassified servers in the server pool 500. 

(Daoud, paragraph 43). 



Daoud's Figure 6 is reproduced below for the convenience of the Examiner: 
FIG. 6 
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(Daoud's Figure 6). 

Daoud describes "service Level 620" in Figure 6 illustrated above as: 
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[0047] When the transaction 200 is received at the load 
balancer 300, the load balancer 300 reads the requested level 
of service from the service tag 220. Based on the server 
index 600 (FIG. 6), the load balancer 300 selects the server 
(e.g., 512) from the server group (e.g., 510) that is best 
providing the requested level of service (e.g., "premium"). 
That is, the server index 600 contains the server ID 610 and 
a corresponding level of service 620, similar to the server 
index 400 in FIG. 4. However, in server index 600, the 
server ID 610 is indicated as a group of servers. That is, 
Servers A, B, and C, are providing a "premium" level of 
service, Servers D and E are providing a "standard" level of 
service, and Server F is providing a low-priority level of 
service. Thus for example, where the service tag 220 indi- 
cates that the requested level of service is "premium", the 
load balancer 300 directs the transaction 200 to any one of 
the servers 511, 512, 513 in the premium group 510. The 
load balancer can use conventional load balancing algo- 
rithms (e.g., next available, fastest available, or any other 
suitable algorithm) to select a specific server 511, 512, 513 
within the premium group 510. 

(Daoud, paragraph 47). 



Even assuming, for the sake of argument, that Ejzak discloses "a session initiation 
protocol and a plurality of SIP entities . . . and a back-to-back user agent" as argued by the 
Examiner, nothing in any of the documents relied upon by the Examiner discloses or suggests the 
combination of features of Applicants' claim 1, namely: 



A method of communicating load, comprising: 

determining a load on a first node; 

factoring the load into a session initiation protocol (SIP) 0-value for the 
first node, where the 0-value is an integer value based on both (1) a contact 
priority and (2) a number of calls or an amount of information being processed for 
a call : 

transmitting the 0-value to a second node via one or more load brokers 
where each load broker is a back-to-back user agent; and 

determining a domain load factor for a domain that comprises a plurality 
of SIP entities, the domain load factor indicating domain load for the entire 
domain, the domain load factor to be shared with other domains and to be used 
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with the 0-value to determine call routing . (Independent claim 1). 
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As stated above, as is well known to those of ordinary skill in the art, a "SIP Q-value" 
(see claim 1) is a specific Session Initiation Protocol (SIP) parameter that has specific 
properties/uses according to SIP . See, e.g., pages 35 and 46 (§§8.1.3 and 10.2.1, respectively) of 
RFC 3261. 3 None of the documents relied upon by the Examiner discloses use of a SIP Q-value 
in any fashion, much less, in the manner argued by the Examiner in the Final Office Action or as 
recited in the claims. Indeed, the term "Q-value" is nowhere found anywhere in any of the 
documents relied upon by the Examiner! 

All of the currently pending independent claims contain the above limitations of claim 1, 
or similar limitations. Thus, all of the currently pending claims contain the above limitations of 
claim 1 or other similar limitations, either directly, or by depending from one of the independent 
claims. 35 USC §112, fourth paragraph. 

These differences between these documents used in the above rejections, and the claims, 
are not merely academic. For example, although the limitations in the claims are not limited to 
or bound by embodiments disclosed in the Specification, in an embodiment disclosed in the 
Specification, these features of the claimed invention that are not disclosed or suggested in these 
documents permit this embodiment to operate in a manner that is different from, and to achieve 
advantages compared to the technology disclosed in these documents. (See, e.g., Specification, 
page 10, lines 14-22). 

Accordingly, since these advantageous features of the claimed invention are nowhere 
disclosed or suggested in any of these documents, it is respectfully submitted that none of these 
documents, taken singly or in any combination, anticipates or renders obvious the claimed 
invention. Therefore, it is respectfully submitted that the Examiner's rejections of the claims 
under 35 USC § 103 cannot be maintained, and should be withdrawn. 

In the event that the Examiner believes that a telephone interview would advance the 
prosecution of this application, the Examiner is invited to call the undersigned attorney to initiate 
an interview. 

In the event that any fees are due or payable in connection with this submission or in this 
application (including any applicable extension of time for response fees) please charge them to 



Additionally, nothing in any of the documents relied upon by the Examiner taken in any combination with 
RFC3261 would disclose or suggest the specific combination of features of the claims. 
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Deposit Account No. 50-4238. Likewise, please credit any overcharges to Deposit Account No. 
50-4238. 



Respectfully submitted, 

Customer Number: 76973 

Date: July 28, 2009 /Christopher K. Gagne. Reg. No. 36.142/ 

Christopher K. Gagne 
Attorney For Assignee 
Reg. No. 36,142 
Telephone No. (817)281-7131 



